Structure health monitoring system and method

ABSTRACT

A structure health monitoring (“SHM”) system according to the invention can be deployed in an onboard environment, such as an aircraft, to provide an ongoing damage assessment of structural components on the aircraft. The SHM system reduces or eliminates time consuming and costly manual inspections of aircraft. The SHM system can leverage known sensor technologies to collect sensor data indicative of the structural health of the monitored components. The sensor data is processed and baselined with sensor feature baselines and damage estimate baselines to provide an accurate final damage estimate for the monitored component. The final damage estimate can be further processed or formatted for compatibility with aircraft maintenance systems.

CROSS-REFERENCES TO RELATED APPLICATIONS

This is a divisional of and claims priority from application Ser. No.10/952,995 entitled “Structure Health Monitoring System And Method,”filed Sep. 28, 2004 now U.S. Pat. No. 7,103,507.

TECHNICAL FIELD

The present invention generally relates to structure health monitoringsystems, and more particularly relates to a structure health monitoringsystem configured for deployment in an aircraft.

BACKGROUND

Certain vehicles, buildings, watercraft, and other structures may besubjected to periodic physical inspections that monitor the health ofvarious components within the structures. For example, commercialaircraft may be routinely inspected to confirm, for example, structuralintegrity. Structural inspections of commercial aircraft are usuallyperformed manually and, therefore, can be labor intensive and costly,especially if a large fleet of aircraft is being maintained. The priorart includes a variety of sensor systems designed to obtain dataindicative of potential structural defects. Such systems, however, donot process the sensor data over time for purposes of trending,reporting, forecasting remaining lifetime, and scheduling maintenance.Furthermore, the prior art does not include a “self-contained” onboardstructure health monitoring system that can be deployed in an aircraft.

Accordingly, it is desirable to have an onboard structure healthmonitoring system configured for self contained deployment on anaircraft. In addition, it is desirable to have a structure healthmonitoring system that processes sensor data over time in connectionwith damage assessments. Furthermore, other desirable features andcharacteristics of the invention will become apparent from thesubsequent detailed description and the appended claims, taken inconjunction with the accompanying drawings and the foregoing technicalfield and background.

BRIEF SUMMARY

An onboard structural health monitoring system according to theinvention can further improve safety margins and reduce the ownershipcost of an aircraft, boat, or vehicle. The system can eliminate manualstructural inspections and provide a capability for prognosticdetermination of remaining lifetime and maintenance scheduling. Theabove and other aspects of the invention may be carried out in one formby a method for monitoring structural health of an apparatus. The methodinvolves obtaining first sensor data, a first damage estimate baselineassociated with said first sensor data, second sensor data, and a seconddamage estimate baseline associated with said second sensor data. Then,a first intermediate damage estimate is generated in response to saidfirst sensor data and said first damage estimate baseline. A secondintermediate damage estimate is generated in response to said secondsensor data and said second damage estimate baseline. The firstintermediate damage estimate and said second intermediate damageestimate are processed to determine a final damage estimate

In another embodiment, a structure health monitoring system for anapparatus comprises at least one sensor configured to provide sensordata indicative of the structural integrity of a component of saidapparatus. The system further comprises a first processing logic forprocessing said sensor data to obtain an initial damage estimate forsaid component and a baseline update element configured to store andupdate a damage estimate baseline for said component. A secondprocessing logic for generating an intermediate damage estimate inresponse to said initial damage estimate and in response to said damageestimate baseline is also provided.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will hereinafter be described in conjunction withthe following drawing figures, wherein like numerals denote likeelements, and

FIG. 1 is a schematic representation of a structure health monitoringsystem suitable for use with an aircraft;

FIG. 2 is a schematic representation of a structure health monitoringsystem suitable for use with an aircraft;

FIG. 3 is a schematic representation of an initial damage estimateprocessor suitable for use with a structure health monitoring system;

FIG. 4 is a flow diagram of an example structure health monitoringprocess; and

FIG. 5 is a flow diagram of an example damage estimation process.

DETAILED DESCRIPTION

The following detailed description is merely exemplary in nature and isnot intended to limit the invention or the application and uses of theinvention. Furthermore, there is no intention to be bound by anyexpressed or implied theory presented in the preceding technical field,background, brief summary or the following detailed description.

The invention may be described herein in terms of functional and/orlogical block components and various processing steps. It should beappreciated that such block components may be realized by any number ofhardware, software, and/or firmware components configured to perform thespecified functions. For example, an embodiment of the invention mayemploy various integrated circuit components, e.g., memory elements,digital signal processing elements, logic elements, look-up tables, orthe like, which may carry out a variety of functions under the controlof one or more microprocessors or other control devices. In addition,those skilled in the art will appreciate that the present invention maybe practiced in conjunction with any number of diagnostic systems andthat the particular implementation described herein is merely oneexemplary application for the invention.

For the sake of brevity, conventional techniques related to datasensors, raw sensor data processing, data cleansing, feature extraction,data fusion, data transmission, and other functional aspects of thesystems (and the individual operating components of the systems) may notbe described in detail herein. Furthermore, the connecting lines shownin the various figures contained herein are intended to representexample functional relationships and/or physical couplings between thevarious elements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical embodiment.

FIG. 1 depicts a simplified schematic representation of a structurehealth monitoring (“SHM”) system 100 that is suitable for deployment inan apparatus such as an aircraft, an automobile, a building, awatercraft, or the like. FIG. 2 is an alternate representation of SHMsystem 100 that only depicts one sensor subsystem. A practicalembodiment of SHM system 100 may be realized as a “combination” of theelements shown in FIG. 1 and FIG. 2. The example embodiment describedherein is deployed in an aircraft such as a commercial airliner. In thisregard, the block elements depicted in FIGS. 1 and 2 may representlogical or functional components that can be implemented in any numberof hardware devices. For example, elements of SHM system 100 can beincorporated into an existing or new avionics module for deployment inan aircraft. As another example, elements of SHM system 100 can beincorporated into computer modules or any suitable onboard processingarchitecture of an aircraft.

SHM system 100 is designed to further improve safety margins and reducethe ownership cost for the aircraft by eliminating unnecessaryinspections. Costly manual inspections are obviated by an onboardinspection system that provides a path towards prognostic determinationof remaining lifetime and maintenance scheduling. A practical embodimentof SHM system 100 can be configured to accommodate the particularapplication and structure being monitored. For example, the number ofsensor subsystems, the sensor types, and the manner in which sensor datais processed may vary from one application to another.

Generally, SHM system 100 is an onboard system that monitors one or morestructural components of the aircraft. SHM system 100 employs one ormore sensor subsystems configured to gather data indicative of thestructural integrity, health, and/or status of the monitored structuralcomponents. The sensor data from each sensor subsystem is processed todetect, locate, size, and characterize any damage condition thatdevelops on a structural component. The processed information may befurther processed, formatted, and rendered for compatibility withaircraft maintenance systems, diagnostic tools, or user interfaces. SHMsystem 100 includes at least one database that preferably containshistorical data, damage estimate baselines, and sensor feature baselinesutilized by SHM system 100 to generate current damage estimates.

SHM system 100 can support any number of sensor subsystems and anynumber of sensor types. In this regard, FIG. 1 shows a first sensorsubsystem 102, a second sensor subsystem 104, and an Nth sensorsubsystem 106. A given sensor subsystem can be configured to detect andcharacterize defects, monitor discrete and continuous loading eventsand/or environmental conditions associated with the structural componentunder observation. For example, a sensor subsystem may be configured todetect anomalies that can be related to the structural integrity of anaircraft door made from composite material. Another sensor subsystem maybe configured to monitor environmental conditions, such as humidity, andto detect the presence of corrosion in the aircraft galleys. Yet anothersensor subsystem may be configured to detect vibrations in critical loadsupporting structural components. SHM system 100 can employ any suitablesensor type and any suitable sensor subsystem—conventional sensorsubsystems known to those skilled in the art can be utilized in thecontext of SHM system 100. For example, SHM system 100 can employ one ormore of the following sensor types, without limitation: ultrasonicguided wave, acoustic emission, electrical resistivity and permittivity,foil and fiber based strain gauges, thermocouples and RTDs,accelerometers, load sensors, or the like.

Each sensor subsystem in SHM system 100 includes at least one sensorthat provides raw sensor data, and processing logic for generating anintermediate damage estimate in response to at least the sensor data.Each sensor can be considered to be a means for obtaining sensor data.FIG. 1 depicts a number of sensors 108 and damage estimate processinglogic 110 associated with first sensor subsystem 102, a number ofsensors 112 and damage estimate processing logic 114 associated withsecond sensor subsystem 104, and a number of sensors 116 and damageestimate processing logic 118 associated with Nth sensor subsystem 106.In practice, a plurality of sensors for a given sensor subsystem can bemounted to or near the structural component (e.g., surrounding a door oralong a load bearing support) and suitably configured to provide thesensor data to the respective damage estimate processing logic.Depending upon the application, the sensors may be coupled to the damageestimate processing logic via wires, cables, physical conduits such asthe structure itself, and/or via wireless links or air channels thatsupport a suitable data transmission protocol.

Although not a requirement of SHM system 100, each sensor subsystemtypically includes an independent group of similar-type sensors anddistinct damage estimate processing logic. In the practical embodiment,the damage estimate processing logic may also process a damage estimatebaseline, repair data, other sensor data, or historical data (describedin more detail below). Each damage estimate processing logic block shownin FIG. 1 is a simplified representation of the processing that occursin a practical implementation. Briefly, a damage estimate processingblock receives the raw sensor data, samples the incoming raw sensordata, converts the raw sensor data into digital form if necessary,distills or concentrates the sensor data into a manageable form,performs initial processing of the sensor data to determine apreliminary or initial damage estimate for the particular sensorsubsystem, and adjusts the initial damage estimate in response to abaseline damage estimate for the particular sensor subsystem. In thisregard, the damage estimate processing logic is one example of a meansfor processing sensor data.

The output of each damage estimate processing logic block is anintermediate damage estimate for the monitored structural component. Asused herein, an “intermediate damage estimate” is any non-finalrepresentation of a damage estimate. In the example embodiment,intermediate damage estimates are processed internally by SHM system 100and need not be rendered or displayed to a user or operator. Moreparticularly, an intermediate damage estimate is a damage estimate thathas been adjusted to compensate for a baseline or historical damageestimate. The various intermediate damage estimates serve as inputs to adata fusion, trending, and tracking element 120. Thus, data fusionelement 120 may receive sensor data for various structural componentsand combine different types of sensor data (regardless of the source andregardless of the component or event being monitored) to generate a moreaccurate assessment of the structural health of the specified component.

Data fusion, trending, and tracking element 120 is configured to processthe intermediate damage estimates and possibly other data to determineor generate a final damage estimate 121. Data fusion, trending, andtracking element 120 receives damage estimates from one or morestructural components and combines these estimates, potentially fromdifferent sensor types, to make a more complete damage estimate for thespecified component. As described in more detail below, data fusion,trending, and tracking element 120 may process historical data fortrending purposes. Accordingly, data fusion, trending, and trackingelement 120 is one example of a means for generating a final damageestimate. As used herein, a “final damage estimate” is the resultantdamage estimate that SHM system 100 calculates for the particularcomponent. As set forth in more detail below, the final damage estimatedata may be further processed, formatted, and/or rendered in a suitablemanner for communication to a user via one or more user interfaces 124.

Data fusion, trending, and tracking element 120 may also receive anyamount of manual inspection data 122. As used herein, “manual inspectiondata” is data that has been collected with human labor, as opposed todata that has been collected via an automated system. Although onepreferred embodiment of SHM system 100 eliminates the need for manualinspection data, a practical embodiment should be capable of processingsuch data if it is available. This feature is desirable to enable SHMsystem 100 to merge manual inspection data 122 with automated sensordata. For example, manual inspection data 122 can be geometricallyregistered with respect to the structure coordinate system andre-sampled (interpolated) at the spatial grid points corresponding tothe automated sensor data collected by SHM system 100 for the monitoredcomponent. Data trending techniques might involve establishing andcompensating for a drift (error accumulation) between manual inspectiondata 122 and the intermediate damage estimates. One practical approachemploys a Kalman filtering framework to accomplish this goal.

Data fusion, trending, and tracking element 120 is configured to performany number of suitable data fusion techniques during the processing ofthe intermediate damage estimates and (optional) manual inspection data122. Briefly, data fusion, trending, and tracking element 120 processesits input data in an intelligent manner to generate a more complete, andgenerally more reliable and accurate assessment of the structural healthof the monitored component. Data fusion, trending, and tracking element120 may utilize fundamental techniques that are known to those skilledin the sensor data processing art, including but not limited to: expertsystem, neural network, and artificial intelligence technologies. Datafusion, trending, and tracking element 120 may also be configured toperform data trending to filter noise from the sensor data and tootherwise enhance the accuracy of final damage estimate 121. Forexample, data fusion, trending, and tracking element 120 may performtime domain and spatial filtering of the intermediate damage estimates.Data trending functionality may include: (1) smoothing, e.g., providingan accurate estimate of the past history of the damage estimatedevelopment; (2) filtering, e.g., computing an accurate noise rejectingestimate of the current structural health state taking into account pasthistory data; and/or (3) prediction, e.g., projecting the damageestimate evolution into the future. The spatial filtering may compute aweighted combination of the various damage estimates at the currentpoint and other spatially close points to provide a more accurate damageestimate at the current point.

In practical embodiments, final damage estimate 121 may be in a formatthat is unrecognizable by maintenance and/or diagnostic equipment, suchas aircraft maintenance systems, personal computers, or the like.Accordingly, final damage estimate 121 may serve as an input to areporting element 126 that is suitably configured to format final damageestimate 121 into at least one useful representation. For example,reporting element 126 may be configured to format final damage estimate121 into at least one displayable damage representation for display on acomputer terminal, a maintenance terminal, or other user interface 124.Reporting element is one example of a means for formatting the finaldamage estimate.

In an aircraft deployment, reporting element 126 preferably formatsfinal damage estimate 121 for compatibility with aircraft maintenancesystems. In this regard, reporting element 126 may generate fault codesin response to final damage estimate 121 or otherwise convert finaldamage estimate 121 into one or more fault codes. Reporting element 126may also process one or more allowable damage limit thresholds 128 inconnection with the formatting of final damage estimate 121. As usedherein, “allowable damage limit thresholds” are damage thresholdsassociated with the monitored structural component. Such thresholds aretypically provided by the manufacturer of the monitored structure,component, or vehicle. Thus, if the final damage estimate does notexceed a given allowable damage limit threshold, then SHM system 100need not generate a damage warning.

In a practical aircraft deployment, reporting element 126 can beconfigured to provide system health information to a central maintenancecomputer in a predefined format of digital messages indicating faults ofthe components in the system. In this regard, the entire structurecovered by SHM system 100 can be divided into a fixed number of zones.For each zone, a fault will be reported if the damage in the zoneexceeds allowable limits and if a structural repair action is required.In addition, damage can be reported in a more detailed manner ifrequested by a maintenance terminal. This information can be moredetailed than fault codes and describe the current state of damageevolution, even if the damage does not trigger the fault code reporting.If only alphanumeric information can be displayed on a given maintenanceterminal, then computational logic will translate the key features ofthe damage estimate array into text messages readable by an operator.

SHM system 100 may include or otherwise communicate with a database 130of histories and baselines. In FIG. 1, database 130 is shown receivingdata from reporting element 126. In a practical embodiment, database 130may be capable of receiving data from data fusion, trending, andtracking element 120, the sensors, and/or the damage estimate processinglogic. Furthermore, as described below, database 130 may be coupled toone or more other elements of a practical SHM system 100. Database 130stores historical damage data that can be used for future damageassessments or for archival purposes. For example, data fusion,trending, and tracking element 120 communicates with database 130 toobtain history data (which are utilized by the trending and filteringalgorithms of data fusion element 120).

FIG. 2 is an alternate representation of SHM system 100. Briefly, FIG. 2only depicts one sensor subsystem 102, separates the correspondingdamage estimate processing logic into a number of elements, and depictsadditional communication paths to and from database 130. The abovedescription of elements contained in FIG. 1 also applies to likeelements contained in FIG. 2.

In a practical embodiment, raw sensor data for a given sensor subsystemcan be gathered by a sensor data concentrator (“SDC”) 150, and eachsensor subsystem can utilize its own SDC 150. SDC 150 functions toexcite active sensors (if applicable), collect raw passive and/or activesensor data, sample the raw sensor data, convert the raw sensor datainto digital form if necessary, filter or process the sensor data, andformat the sensor data for manageable delivery to an initial damageestimate processing logic element 152. SDC 150 may leverage conventionaltechnologies and SDCs are known to those skilled in the sensor dataprocessing art.

Initial damage estimate processing logic element 152 is suitablyconfigured to process sensor data to obtain an initial damage estimate154 for the monitored structural component. As used herein, an “initialdamage estimate” is any non-final representation of a damage estimate.In the example embodiment, initial damage estimates are processedinternally by SHM system 100 and need not be rendered or displayed to auser or operator. More particularly, an initial damage estimate is adamage estimate generated by the sensor subsystem based on the currentreadings of the sensors and the baseline, and an initial damage estimateneed not take into account historical data, data from other sensorsubsystems, and auxiliary data (such as manual inspection data). In apractical embodiment, processing logic element 152 can generate initialdamage estimate 154 in response to one or more optional pieces of data,including, without limitation: sensor data 156 from other sources suchas additional sensor subsystems; repair data 158, which includes sensorrepair data and component repair data; and sensor feature baseline data,which may be provided by database 130.

Fundamentally, processing logic element 152 receives the sensor datafrom SDC 150 and computes an initial estimate of the structural damageor health of the monitored component. Processing logic element 152 mayinclude algorithms developed by the provider of the sensor subsystem,algorithms co-developed by the manufacturer of the monitored structure(e.g., an aircraft manufacturer), or algorithms co-developed by theprovider of SHM system 100. In one practical implementation, the mainoutput of processing logic element 152 will be a damage estimate array,where the array elements are estimates of the damage intensity atpre-defined grid points of the monitored structural component. In atypical deployment there might be 200-300 sensors 108 located around thecomponent and perhaps 20,000 grid points for the damage estimation.

FIG. 3 is a high level schematic representation of an initial damageestimate processor 300 suitable for use with SHM system 100. Processinglogic element 152 may utilize processor 300 or some variation thereof.The sensor data 302 is reduced into a set of features by suitablyconfigured feature extraction logic 304. The specific features mightdiffer depending upon the particular application and approach, buttypically can be computed using standard and well defined signalprocessing methods. For example, feature extraction logic 304 maycompute time-of-flight, signal amplitude, FFT coefficients, or waveletcoefficients for the collected sensor data 302. The extracted features306 are then baselined against the nominal state of the monitoredstructural component. In this regard, a feature baseline 308 (providedby feature baseline processing logic 310) is subtracted from extractedfeatures 306 to obtain baselined features 312. Baselined features 312are then processed by damage estimation logic 314, which generates theinitial damage estimate 316.

An additional input to initial damage estimate processor 300 is repairdata 158, which represents repair data for the structural component,sensors 108, SDC 150, or any other component or feature that might havean impact on the calculation of initial damage estimate 316. A recentrepair presumes that there is no remaining damage in the structuralcomponent and, therefore, indicates a need to reset the feature baseline308. This ensures that an observed change in the structural behavior ofthe component is related to damage rather than to a recent repair.Referring again to FIG. 2, feature baseline 308, and historical datarelated to the operation of initial damage estimate processor 300 can bestored in database 130 and uploaded into initial damage estimateprocessing logic element 152 when required.

Referring again to FIG. 2, initial damage estimate processing logicelement 152 provides only a part of the necessary calculations in theexample embodiment. For example, a damage estimate baseline 160(provided by a damage estimate baseline element 162) is subtracted frominitial damage estimate 154 to obtain an intermediate damage estimate164. Notably, damage estimate baseline 160 is distinct from featurebaseline 308 (see FIG. 3) and serves a different purpose. Featurebaseline 308 is the reference data acquired at the feature baselinereset time. Feature baseline 308 is used to estimate the damage as achange with respect to the reference state of the component. On theother hand, damage estimate baseline 160 is computed by damage estimatebaseline element 162 and is used to ensure a continuity of the baselineestimation in the absence of structural repairs.

As one example, consider replacement of the sensors or analog sensorelectronics. Since the sensors are slightly different, this will lead tooffsetting damage estimates. In that scenario, feature baseline 308should be updated to capture a new reference state of the structure. Asa result, initial damage estimate 154 will be zero. This new referencestate would not in itself account for previous damage, however, sincereplacing sensors does not change the damage to the monitored component,a suitably configured baseline update logic contained in damage estimatebaseline element 162 could be used to compute the new damage estimatebaseline 160. This new baseline would be configured in such a way thatthe new damage estimate is exactly the same as the last damage estimateobtained before the sensor repair. A more advanced possible use ofdamage estimate baseline 160 would be in the case where there aremultiple partial damage spots in addition to a heavier damage spot,which is repaired by applying a local patch. In that case, the baselineshould be updated such that the damage estimate is zero in the repairvicinity, while remaining the same elsewhere.

Damage estimate baseline logic 162 may also update damage estimatebaseline 160 in response to repair data 158 (e.g., sensor repair data,component repair data, SHM system repair data, or the like) as depictedin FIG. 2. In this context, logic 162 is one example of a means forupdating damage estimate baseline 160.

As shown in FIG. 2, database 130 may be coupled to one or morecomponents or logical elements of SHM system 100. As described above,database 130 can receive historical damage data from reporting element126. Database 130 may be coupled to (or otherwise communicate with) datafusion element 120 to provide such historical data for purposes oftrending and/or filtering. Database 130 is also coupled to damageestimate baseline logic element 162 to facilitate the loading ofbaselines at start-up and the storage of baselines on disk in responseto updating. Furthermore, database 130 can be coupled to processinglogic element 152 to facilitate the loading of feature baselines atstart-up and the storage of such baselines on disk in response toupdating.

Database 130 is preferably configured to collect and store the SHM statedata, including baselines and histories. In practical embodiments,database 130 can include, without limitation: feature baselines used inconnection with the initial damage estimate processing; damage estimatebaselines used to obtain the intermediate damage estimates; damageestimate history up to a predefined historical depth (e.g., the last1000 estimates); fault codes for SHM system 100; text damage reports andtheir histories; and structural repair data. The SHM data stored indatabase 130 will be provided to SHM system 100 at restart and whenrequested by the system. The text report data can also be requested atany time from a maintenance terminal or any suitably deployed userinterface. The SHM data stored in database 130 can also be madeaccessible to external computer devices, networks, or architectures viaa wireless link or other suitable data communication channel. Thedetailed SHM data from database 130 can be used for sustainedengineering of SHM system 100 and/or for algorithm maturation (which mayapply to initial damage assessment algorithms, data fusion, trending,and tracking algorithms, baseline update algorithms, or the like).

FIG. 4 is a flow diagram of an example SHM process 400 that may beperformed by a SHM system, such as SHM system 100 as described herein.Process 400 may be performed and/or controlled by one or more of thelogic and/or processor elements described herein. In a practicalimplementation, process 400 may include any number of additional and/oralternative tasks, and process 400 may be incorporated into a morecomplex SHM procedure. Furthermore, the tasks depicted in process 400need not be performed in the order shown in FIG. 4 and one or more ofthe tasks may be performed concurrently in a practical embodiment.

SHM process 400 can begin by obtaining historical data, featurebaselines, damage estimate baselines, and other data at start-up (task402). As mentioned above, these items can be retrieved from a suitabledatabase and loaded into one or more elements of the SHM system. Task402 may obtain any number of feature baselines corresponding to anynumber of sensor subsystems and sensor types. Likewise, task 402 mayobtain any number of damage estimate baselines corresponding to anynumber of sensor subsystems. As described above in connection with FIG.1, SHM system 100 is capable of processing sensor data from multiplesensor subsystems. Accordingly, SHM process 400 may identify orotherwise begin processing for a first sensor type or subsystem (task404).

SHM process 400 obtains sensor data for the first sensor subsystem (task406) and processes that sensor data to generate a correspondingintermediate damage estimate (task 408). An example process forgenerating intermediate damage estimates is described below inconnection with FIG. 5. If there are more sensor subsystems to be polled(query task 410), then SHM process 400 identifies or otherwise beginsprocessing for the next sensor type or subsystem (task 412). Thereafter,SHM process 400 can be re-entered at task 406 such that intermediatedamage estimates are obtained for each of the sensor subsystems.

After all of the intermediate damage estimates have been obtained, SHMprocess 400 processes the intermediate damage estimates as describedabove to determine a final damage estimate (task 414). The final damageestimate is generated in response to the initial damage estimates, inresponse to the damage estimate baselines, in response to theintermediate damage estimates, and (optionally) in response to manualinspection data. The final damage estimate can be formatted forreporting (task 416) in any suitable manner and for compatibility withthe available diagnostic tools and/or user interfaces. During task 416,the SHM system may process one or more allowable damage limits orthresholds for the monitored components, as described above. In onepractical embodiment, the final damage estimate is formatted into atleast one displayable damage representation. SHM process 400 can renderthe formatted final damage estimate into a suitable form and provide thefinal damage estimate to one or more users. For example, the finaldamage estimate can be displayed in a graphical format, displayed in analphanumeric format, represented as one or more alarms, or the like. SHMprocess 400 may also update the SHM system database to reflect changesor additions to historical data, feature baselines, and/or damageestimate baselines (task 420).

FIG. 5 is a flow diagram of an example damage estimation process 500that may be performed by a SHM system, such as SHM system 100 asdescribed herein. Process 500 may be performed and/or controlled by oneor more of the logic and/or processor elements described herein. In apractical implementation, process 500 may include any number ofadditional and/or alternative tasks, and process 500 may be incorporatedinto a more complex SHM procedure. Furthermore, the tasks depicted inprocess 500 need not be performed in the order shown in FIG. 5 and oneor more of the tasks may be performed concurrently in a practicalembodiment.

Briefly, damage estimation process 500 relates to the generation ofintermediate damage estimates that can be further processed by SHMsystem 100 as described above. Process 500 can begin by obtaininghistorical data, feature baselines, damage estimate baselines, and otherdata at start-up (task 502). As mentioned above, these items can beretrieved from a suitable database and loaded into one or more elementsof the SHM system. If new repair data is available (including, but notlimited to, sensor repair data, component repair data, or SDC repairdata), then process 500 obtains the repair data (task 504) and updatesone or more damage estimate baselines in response to the repair data(task 506). This ensures that SHM system 100 considers changes to thestructural component and/or measurement equipment when determining thedamage estimates. Any updated damage estimate baselines are preferablystored in database 130 for future reference (task 508).

Once SHM system 100 has been initialized and updated, damage estimationprocess 500 can obtain raw sensor data, which may be active sensor dataand/or passive sensor data for a given sensor subsystem (task 510).Process 500 may also perform an optional task 512 to obtain manualinspection data that can be used to supplement the sensor data obtainedduring task 510. The sensor data obtained during task 510, or aconditioned, concentrated, or processed version of the sensor dataobtained during task 510, can then be processed to obtain an initialdamage estimate (task 514). During task 514, process 500 may alsoprocess repair data such that the initial damage estimate is generatedin response to the sensor data and the repair data. Process 500 may alsogenerate the initial damage estimate in response to the manualinspection data.

The current damage estimate baseline associated with the particularsensor subsystem is subtracted from the initial damage estimate toobtain the intermediate damage estimate (task 516). A practicalembodiment of SHM system 100 may employ other baseline adjustmenttechniques and different algorithms to generate intermediate damageestimates in response to initial damage estimates and baseline values.For example, damage estimation process 500 may process manual inspectiondata or other sensor data to generate the intermediate damage estimate.As described above, the intermediate damage estimate can serve as aninput to a data fusion, trending, and tracking element that generates afinal damage estimate for the given structural component.

EXAMPLE DEPLOYMENT Composite Structure Monitoring

SHM system 100 can be deployed in a number of practical environments tomonitor health of many different structural components. One practicaldeployment of SHM system 100 employs a network of Lamb wave transmittersand receivers to interrogate composite structures such as an aircraftfuselage around cargo door bays. The use of Lamb waves fornondestructive inspection is well known, and, therefore, the details ofLamb wave analysis are not presented herein.

There are two main classes of imperfections in continuous fibercomposites: (1) manufacturing defects and (2) in-services damageaccumulations. Manufacturing defects include processing generatedanomalies such as delaminations, misorientation of fibers, resin-richand resin-poor regions, incomplete or incorrectly cured matrix material,porosity and larger gas-generated voids. These manufacturing variancesgenerally result in reduction in the composite mechanical properties andas such should be identified and controlled during the manufacturingprocess.

During usage, both incremental and discrete damage can accumulate.Fatigue (incremental) damage is characterized by initiation and growthof cracks from multiple sites near a high stress region. Althoughcomposites perform very well under cyclical loading, given theappropriate conditions matrix cracking can lead to fiber breakage,furthered by crack coupling, interfacial debonding, delamination growthand ultimate fracture.

Discrete damage can occur from the impact of an object onto the surfaceof the composite. Generally, the impact initiates a shock wave at thepoint of impact spreading as it travels and causes its largest effectbelow the surface. Thus, a small surface mark can presage a moresignificant sub-surface damage state. In the past, surface abrasions andend ply section have provided a preferential path for water ingressionand absorption by the matrix resins. For certain resins this leads todeterioration and reduced strength. SHM system 100 can eliminate orreduce the amount of manual maintenance inspections and repair actionsby discerning damage evolution of the composite material.

Traditionally, ultrasound and X-ray techniques have been the principalmethods used to nondestructively inspect composites. The most commonultrasonic approach is to employ a contact transducer to generate andcollect bulk elastic waves that travel through the material thicknessand reflect back from anomalies. In order to cover an area of interest,the transducer is either manually or automatically scanned over the areaof concern.

A number of sensor/algorithm solution providers employ ultrasonic Lambwaves to interrogate composite structures. Lamb waves are guided elasticwaves distinct from the bulk elastic waves used in the traditionalultrasonic approach. Lamb waves can travel in any directionperpendicular to the plate thickness direction, and as a consequence ofthe wave motion, cause small local material displacement throughout theplate's thickness. Schemes using distributed networks of sensors can bedevised to examine the composite “plate” throughout its thickness over agiven area without the need to reposition the Lamb wave transducers.This ability makes these elastic waves attractive for SHM system 100.

These large arrays of Lamb wave sensors are capable of generating hugeamounts of data. In an avionics environment it is essential to compressthis data into a form that can be used for analysis and storage.Generically, this is the process of feature extraction, where salientfeatures of the data are deduced and consequently the data iscompressed. These features, e.g., time of flight, signal amplitude, andsignal “energy” (area under the rectified voltage curve), are then usedin a model to predict the underlying damage state of the area traversedby the elastic waves.

Estimation of the composite damage requires modeling because it is verydifficult to measure the damage directly. Thus, the damage is inferredfrom the data using either physical (first principal) models, datacentric models, or a combination of the two approaches. Physics basedmodels predict system behavior by examining the first principalrelationship between the system stimulation and responses. Although afirst principal approach may sound fundamentally more attractive, eachof approaches has strengths and weaknesses. A pattern recognitionapproach improves as the quantity and quality of relevant data grows,while a first principal model improves as the sophistication of themodel accounts for higher order and more subtle effects.

While at least one example embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. For example, although SHM system 100 can beconfigured to accommodate data collected from Lamb sensors, it is not solimited. Indeed, practical deployments of SHM system 100 can becustomized to accommodate any number of different sensor subsystems andany number of different sensor types. It should also be appreciated thatthe described embodiment or embodiments are only examples, and are notintended to limit the scope, applicability, or configuration of theinvention in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the example embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope of theinvention as set forth in the appended claims and the legal equivalentsthereof.

1. A structure health monitoring system for an apparatus, said structurehealth monitoring system comprising: at least one sensor configured toprovide sensor data indicative of the structural integrity of acomponent of said apparatus; first processing logic for processing saidsensor data to obtain an initial damage estimate for said component; abaseline update element configured to store and update a damage estimatebaseline for said component; and second processing logic for generatingan intermediate damage estimate for said component in response to saidinitial damage estimate and in response to said damage estimatebaseline, wherein the intermediate damage estimate serves as an inputfor a data fusion, trending, and tracking element.
 2. A structure healthmonitoring system according to claim 1, wherein the data fusion,trending, and tracking element is configured to process saidintermediate damage estimate and manual inspection data to determine afinal damage estimate.
 3. A structure health monitoring system accordingto claim 2, further comprising a reporting element configured to formatsaid final damage estimate into at least one displayable damagerepresentation.
 4. A structure health monitoring system according toclaim 3, wherein: said apparatus is an aircraft, and said reportingelement formats said final damage estimate for compatibility withaircraft maintenance systems.
 5. A structure health monitoring systemaccording to claim 1, wherein said first processing logic also processessensor repair data to obtain said initial damage estimate for saidcomponent.
 6. A structure health monitoring system according to claim 1,wherein said first processing logic also processes repair data to obtainsaid initial damage estimate for said component.
 7. A structure healthmonitoring system according to claim 1, wherein: said apparatus is avehicle; and said at least one sensor, said first processing logic, saidbaseline update element, and said second processing logic are onboardsaid vehicle.